Information security method and system

ABSTRACT

The present invention discloses an improved information security system and method. A polymorphic engine is used to enhance the security features of a software application and the data generated by or made available to the application and/or the operating system. The polymorphic engine operates to randomly alter the standard executable code of the original application while preserving its functional characteristics. Each polymorphed instance of the application differs from any other instance of the same application in form only. Various other security features operate to protect the polymorphic engine itself and/or the polymorphed code generated therefrom. These other security features include: just-in-time instruction code decryption; virtual CPU instruction code pre-processing; call mutation; stack manipulation; secure hook-capture of device input; secure display device output; application level decryption of encrypted hardware data streams; and a dynamic, randomly configured graphical keypad interface.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No.09/855,073, filed on May 14, 2001, which claims priority to U.S.Provisional Patent Application Ser. No. 60/203,877 entitled “INFORMATIONSECURITY SYSTEM” filed on May 12, 2000, which is incorporated herein byreference.

FIELD OF THE INVENTION

This invention generally relates to information security systems. Morespecifically, the invention relates to a system and method for improvingthe security features of executable computer program code and/or datawhich is generated, stored or manipulated by program code in order tomore effectively prevent theft, decompilation, unauthorized reproductionand/or unauthorized use.

BACKGROUND OF THE INVENTION

As computers have become more widely used and more pervasivelynetworked, information, privacy, and financial losses, etc., due toinformation security breaches have dramatically increased as well.According to a Mar. 12, 2001 survey press release, published by theComputer Security Institute, eighty-five percent of 538 respondents,primarily large corporations and government agencies, detected computersecurity breaches in the preceding year.(http://www.gocsi.com/prelea.sub- .—000321.htm, incorporated herein byreference.) Sixty-four percent of the same respondents confirmedfinancial losses due to computer breaches, with thirty-five percent of186 respondents being capable of quantifying their losses as totalling$377,828,700. By comparison, the losses from 249 respondents in 2000totalled $265,589,940, with the average annual total over the priorthree year period being $120,240,180. This trend illustrates that thethreat of computer crime and other electronic information securitybreaches continues to grow with financial loss exposure also increasing.

As in previous years, the most serious financial losses have occurredfrom theft of information (34 respondents reporting $151,230,100) andfraud (21 respondents reporting $92,935,500). Notably, those respondentsthat cited their Internet connections as a frequent point of attack rosefrom 59% in 2000 to 70% in 2001. Some examples of security breaches andcyber crimes on the rise are: system penetration from external sources(40% of respondents); denial of service attacks (38%); employee abuse ofInternet access privileges, for example downloading pirated software orinappropriate use of email systems (91%); and computer virus attacks(94%).

Many advances have been made in recent years in the field of computerinformation security. Most of these security countermeasure technologieshave employed computer software to: identify authorized users of asystem; protect against virus infection; encrypt/decrypt data streams;prevent unauthorized registration and/or use of pirated softwareapplications; and block malicious or surreptitious communicationsoriginating from a particular source. Unauthorized access to aparticular computer system, however, may often be obtained by exploitingvarious security flaws present in the program code of the countermeasuresoftware itself. Additionally, unauthorized access may also occur withthe theft of user identification and password information.

With respect to the unauthorized and illegal reproduction of computersoftware, one of the most prevalent problems is that the softwareapplications can be reverse engineered with decompiling tools.Decompilers are essentially software applications that examine othercompiled software applications in order to reconstruct the originalsource code. For commercial software applications offered for sale,decompilation and reverse engineering is often prohibited by softwarelicense agreements. Decompilers, however, are freely available for avariety of platforms. Generally, a decompiler works by analyzing thebyte code of software and making educated guesses about the source codethat created it. Most decompilers also provide additional debugginginformation, which can help the decompiler generate a more accuraterepresentation of the original source code. If the software employs coderoutines for protecting itself against unauthorized use, such as withthe aid of serial numbers, hardware locks, locking to floppy disks orCD's, time-limited license expiration, etc., the code fragments can bedecompiled, analyzed, modified and recompiled to produce a new versionof the software application in which the security code routine has beendefeated and is no longer capable of preventing unauthorized use. Themodified software application is thereafter unprotected and may beduplicated and distributed ad infinitum for illegal, royalty-free use,for example, over the internet as what is known to those skilled in theart of software piracy as “warez”.

Several debugging tools, such as, for example, NUMEGA.RTM. SOFTICE.RTM.,are readily available for this purpose.(http://www.numega.com/drivercentral/components/si_driver.shtml). Adebugging tool, more commonly known as a “debugger”, is a softwaredevelopment program that allows the user to debug and troubleshootcomputer code as the application is being developed. Generally, thedebugger acts to interrupt the CPU in order to watch each individualinstruction as it arrives for processing and execution. For example, adebugger may be used to analyze and determine precisely which codefragment in a compiled application is responsible for interrogatingwhether a valid serial number has been provided in order to permit anauthorized user to execute the program application. Once the serialnumber interrogation code fragment is located by the debugger, itbecomes rather simple to decompile the code fragment to determine thecharacteristics that a valid serial number key must have in order topermit program execution access. For example, for any serial numberinterrogation code fragment and any valid serial number, the operationof the code fragment on a valid serial number s permits user access(1=True; therefore, allow access) as given by: s=1 and the operation ofthe interrogation code fragment on an invalid serial number x deniesuser access (0=False; therefore, deny access) as given by: x=0. Giventhe code fragment, an inverse function .sup.-1 may be derived such that:1i C{circumflex over ( )}-1Ri=isii=1 n C{circumflex over ( )}s i=n,wherein, any operation of the inverse function .sup.-1 upon a randomseed R.sub.i generates a random and valid serial number s.sub.i.Moreover, an algorithm may be deduced from the inverse function of thecode fragment .sup.-1 to generate a stand-alone application capable ofgenerating multiple random, yet valid, serial numbers. Alternatively,the interrogation code fragment may be removed altogether and theprogram recompiled to a version which no longer has an interrogationcode routine and that looks for a serial number prior to permitting theuser to execute the application.

Another representative software security weakness involves theMICROSOFT.RTM. WINDOWS.RTM. Application Programming Interface (API). Forexample, when the user displays a webpage requesting that the userlogin, there may be a textbox provided for the username and anothertextbox for the password. Using the WINDOWS.RTM. API, anotherapplication can continuously or periodically request the contents of thetextboxes, even if the webpage display subroutine passes asteriskcharacters to obscure that content. Such an application can be designedto run in the background and would be generally undetectable to theaverage user.

Yet another exploitable software security vulnerability involves thelogging of user keystrokes. In these types of breaches, an applicationcan monitor the data originating from the operating system's keyboarddevice driver routines to look for username, password or other sensitivedata and store and/or transmit the data for future use. Additionally,keyboards, like most electronic devices, generally emit electromagneticradiation of particular frequencies which propagate away from thekeyboard in all directions. Someone monitoring these frequencies at adistance can analyze the signals to determine which keys on the keyboardhave been depressed.

The “cut and paste” feature of many operating systems also presents asecurity problem. Each time the cut-and-paste feature is used, forexample, in MICROSOFT.RTM. WINDOWS.RTM., another application caninterrogate the clipboard and make copies of the contents. There aremany other examples of exploiting software security flaws that involveother mechanisms, such as digital wallets/passports, web browsercookies, etc. Often, a computer virus is selected as a transportmechanism for depositing these malicious applications onto a targetcomputer system.

There is a need, therefore, within the electronic information securityart, to more effectively counter the exploitation of security flaws insoftware applications during the execution of the application code.There is also a need to more effectively prevent (1) unauthorizedduplication and distribution of software applications and (2) thecapturing of identification, password and/or other data that might beused, inter alia, to gain access to a particular computer system.

SUMMARY OF THE INVENTION

In general, the present invention suitably protects standard and/orcustom compiled code using a polymorphic engine which randomly altersthe executable code of a compiled application while conserving theapplication's original operational and functional characteristics. Oncethe code has been randomly polymorphed, it becomes statisticallyimpossible to retrieve the original application source code.Additionally, each polymorphed copy of the application randomly differsfrom any other copy and, therefore, precludes the possibility ofgenerating a patch or crack for any one polymorphed copy that will workgenerically with any other polymorphed copy of the application.Moreover, the code polymorphing process can be iteratively applied togenerate multiple layers of protection.

In order to protect the polymorphic engine from debugging, decompilationand/or reverse engineering by analysis of memory snap-shots, a runningline encryption method, is also disclosed, which protects thepolymorphic engine while the engine's code resides in memory. This isgenerally accomplished by having only one line of the engine's encryptedinstruction code decrypted for any given CPU instruction cycle. As thepolymorphic engine's code moves through the stack to be processed by theCPU, these instructions are decrypted “just-in-time” and provided to theCPU for execution, and then immediately re-encrypted before decryptionand subsequent execution of the next line of instruction code. Thepresent invention also discloses a virtual CPU instruction setpre-processor employing a matchable data structure that is randomlycreated when the polymorphed application initializes. The matchable datastructure correlates instructions specific to the CPU's instruction setwith virtual CPU opcodes generated by the polymorphic engine.

As an added layer of protection, the present invention also disclosesstack manipulation and call mutation features that operates with thepolymorphic engine to further subvert attempts to analyze and reverseengineer the application code. For applications or operating systemsthat use member calls to classes where the calls contain certain headerdata required by the class member to function properly, the callmutation feature operates as an execution sequence redirector by: (1)inserting mischievous data into the header of the original call, therebyrendering the original call ineffective; (2) rerouting the original callto a substitute call in which the substitute routine queries the stackpointer to determine where the substitute routine has been called from;and (3) comparing the data obtained from the stack to a matchable datastructure in order to pass program execution control to the appropriateroutine. The software application still includes similar or identicalfunctionality, but the header of the original call is different and notreadily traceable. This process can be iteratively applied to generatemultiple layers of protection and may also be applied to API or otherpointers as well.

A secure output display interface for concealing data, protects usersfrom applications that may use operating system calls to capture data byplacing a hook into OS routines that preprocess input, (i.e., from akeyboard, mouse, light pen, etc.) and by interpreting the input beforeit is made available to other OS processes. The hook-captured input isthen enciphered and hidden from the OS. For example, a user passwordentered in a textbox could be hook-captured from the keyboard devicedriver, enciphered and stored, and then the hook routine passes literalasterisk characters to the appropriate textbox. In such a system,queries from other OS routines to the textbox object would return theseries of asterisks characters placed there by the hook routine and notthe literal text of, for example, a password entered by the user. In oneof the various aspects of the present invention, the hook-captureroutine helps to secure user input to the polymorphed application bymodifying display device output as well as corresponding literal dataobject content.

Another security feature of the present invention involves a securehardware input device driver interface (i.e., keyboard, mouse, lightpen, Ethernet cards, etc.) for entering secure data content. In oneaspect of the present invention, the polymorphed applicationcommunicates with an encryption chip located within the user inputdevice to notify the device when encrypted communication is desired. Allother communication with the input device, in the absence of a requestfor encrypted data traffic, will be unencrypted. Encrypted data streamsfrom the input device are decrypted at the polymorphed code applicationlevel, not the hardware or OS level, in order to prevent backgroundapplications from obtaining the decrypted data stream.

In yet another embodiment of the present invention, a secure softwareapplication for entering authentication information (i.e., username andpassword data, etc.) is described. The authentication application is adynamic, randomly configured, graphical keypad display, which isdesigned to subvert optical capture/recognition and hardware inputdevice logging.

BRIEF DESCRIPTION OF EXEMPLARY DRAWINGS

The above and other features and advantages of the present invention arehereinafter described in the following detailed description ofillustrative embodiments to be read in conjunction with the accompanyingdrawings and figures, wherein like reference numerals are used toidentify the same or similar system parts and/or method steps in thesimilar views and:

FIG. 1 is a schematic diagram of exemplary steps for generating a codepolymorph in accordance with one aspect of the present invention.

FIG. 2 is a schematic diagram demonstrating an exemplary generation ofmultiple code polymorphs from a compiled executable program inaccordance with another aspect of the present invention.

FIG. 3 is a schematic diagram depicting an exemplary generation of alayered code polymorph with the iterative application of the polymorphicalgorithm to the code polymorph produced therefrom in accordance withanother aspect of the present invention.

FIG. 4 is a schematic diagram depicting an exemplary prior art systemand method for entering user input into a textbox data object.

FIG. 5 is a schematic diagram depicting an exemplary system and methodfor securely entering user input into a textbox data object inaccordance with another aspect of the present invention.

FIG. 6 is a schematic diagram depicting an exemplary system and methodfor securely communicating encrypted user input to an application inaccordance with another aspect of the present invention.

FIG. 7 is a display screen-shot depicting an exemplary system and methodfor securely entering user input that is designed to frustrate attemptsto optically capture and/or device log input data in accordance withanother aspect of the present invention.

FIG. 8 is a schematic diagram depicting an exemplary system and methodfor the mutation of a subroutine call in accordance with another aspectof the present invention.

FIG. 9 is a schematic diagram depicting an exemplary system and methodfor securely executing application code in accordance with anotheraspect of the present invention.

FIG. 10 is a table depicting an exemplary set of candidate instructionswhich lend themselves to substitution with functionally isomorphicinstructions in accordance with another aspect of the present invention.

FIG. 11 is a table depicting exemplary benign instructions for insertioninto polymorphed code in accordance with another aspect of the presentinvention.

FIG. 12 is a table depicting an exemplary process that utilizes runningline encryption in accordance with another aspect of the presentinvention FIG. 13 depicts an exemplary EIP look-up table in accordancewith another aspect of the present invention.

FIG. 14 depicts an exemplary import address table having an indexed,encrypted list of the original API place holders in accordance withanother aspect of the present invention.

FIG. 15 is a table depicting an exemplary correlation chart for mutationof API calls in accordance with another aspect of the present invention.

FIG. 16 is a table depicting an exemplary method for mutation of APIcalls using the INTEL.RTM. instruction set in accordance with anotheraspect of the present invention.

FIG. 17 is a schematic diagram depicting an exemplary system and methodfor protecting provisional use software in accordance with anotheraspect of the present invention.

FIG. 18 is an exemplary schematic diagram depicting prior artrelationships between application code, application data and the programstack.

FIG. 19 is a schematic diagram depicting an exemplary system and methodfor manipulation of the program stack in accordance with another aspectof the present invention.

FIG. 20 is an exemplary schematic diagram depicting a prior art systemand method for encrypting compiled program code.

FIG. 21 is a schematic diagram depicting an exemplary system and methodfor protecting compiled code using a random encryption/decryptionprocess in accordance with another aspect of the present invention.

Other aspects and features of the present invention will be more fullyapparent from the detailed description that follows.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention offers substantial advantages and improvementsover existing electronic information security technology with respect tothe security features of executable application code and/or data whichis generated, stored or manipulated by the application code in order tomore effectively prevent unauthorized reproduction, access and/or use ofthe same. In accordance with various exemplary embodiments disclosedherein, the present invention operates to protect standard or customcompiled code using a polymorphic engine which randomly alters thestandard executable code of a compiled application while conserving theapplication's original operational and functional characteristics. Othermethods and systems for protecting data traffic to and from thepolymorphed application and the polymorphic engine itself are alsodescribed.

The following descriptions are of exemplary embodiments of the inventiononly, and are not intended to limit the scope, applicability orconfiguration of the invention in any way. Rather, the followingdescription is intended to provide convenient illustrations forimplementing various embodiments of the invention. As will becomeapparent, various changes may be made in the function and arrangement ofthe elements described in these embodiments without departing from thespirit and scope of the invention.

FIG. 1 depicts an exemplary method and system for modifying compiledexecutable application code 10 employing a polymorphic algorithm 15 togenerate an executable code polymorph 20. Source code 1 is compiled(step 100) to object code 5 and thereafter linked (step 110) to generatea compiled executable program 10. In an alternative exemplaryembodiment, source code 1 may be more directly converted to executableprogram code 10 without generating and linking object code 5, such as inthe case of the source code 1 being authored in an interpreted languagesuch as, for example, XML, DHTML, Basic, LISP, Java, Visual Basic,Install Shield, various scripting languages and/or any programming ormark-up language or combination of languages, now known or later derivedby those skilled in the art, employing the use of non-CPU and/ornon-native code. A random polymorphic engine 15 scans the code (step115) of the compiled executable 10 to look for predetermined candidateinstructions to be replaced with random functionally isomorphicinstructions. In one exemplary embodiment, this may be accomplished byrandomly selecting an entry in an instruction look-up table. Such alook-up table might comprise, for example, four different options foraccomplishing the result of adding two numbers together using theinstruction set of a particular CPU. FIG. 10 depicts a set of exemplarycandidate instructions in accordance with, for example, a representativesubset of INTEL.RTM. instruction codes which lend themselves tosubstitution with multiple functionally isomorphic replacement options.Those skilled in the art will appreciate that the present invention maybe applied to a variety of CPU architectures employing variousinstruction sets now known or hereafter derived.

In an alternative exemplary embodiment of the present invention, benigninstructions may also be inserted into the polymorph instruction code 20to further differentiate the polymorph 20 from the original compiledexecutable 10 without altering the functional operation of thepolymorphed code 20. Generally, a benign function is an instruction, ora set of instructions, whose operation is inconsequential to the overalloperation, function or result of the remainder of the application code.FIG. 11 depicts exemplary benign instructions wherein, where possible,an alternative instruction is selected randomly to replace afunctionally benign instruction.

Once the isomorphic instructions have been substituted for originalinstructions (step 120), the resulting code polymorph 20 is physicallydifferent from the original compiled executable 10, yet hassubstantially the same operational and functional characteristics. Theprocess, shown in FIG. 1, of generating a code polymorph may be moreconcisely represented by the following: .PSI.=o where represents theoriginal compiled executable 10, .PSI. represents the set of data,parameters and/or variables operated on by, and o represents the resultgenerated by execution of the original compiled code 10. The polymorphicalgorithm 15 operates to perform a substantially unitary transformationof the original compiled code 10 to generate a functionally isomorphiccode polymorph 20 as in the following:{circumflex over (X)}(.PSI.)={circumflex over (X)}*.PSI.=owhere {circumflex over (X)} represents the polymorphic algorithm 15whose action on the originally compiled executable code 10 ( ) generatesa code polymorph 20 ({circumflex over (X)}*), which when applied to theset of data, parameters and/or variables (.PSI.) typically operated onby the originally compiled code 10 ( ) produces substantially the samefunctional result o. Therefore, the unitary transformation performed bythe polymorphic algorithm 15 ({circumflex over (X)}) on the originallycompiled code 10 ( ) may also be represented by: .therefore.{circumflexover (X)}(.PSI.)=.PSI. where the operation of the polymorphic algorithm15 ({circumflex over (X)}) may be more simply considered as anyrepresentative or exemplary unitary transformation, such as, forexample, multiplication of a particular value by the quantity 1. In thepresent invention, however, the polymorphic engine 15 is not consideredto be merely limited to performing mathematically unitarytransformations of the original compiled code 10, but also functionallyunitary transformation of individual and/or blocks of CPU instructionsthemselves. Therefore, the generated code polymorph 20 ({circumflex over(X)}*) is said to constitute a functionally isomorphic variant of theoriginally compiled code 10 ( ) having the property, inter alia, ofbeing statistically impossible to reverse engineer in attempts toregenerate the original code 10.

The polymorphic engine 15, in one exemplary embodiment of the presentinvention, is configured to randomly scan, select, assign and/orsubstitute isomorphic code fragments that are functionally correlated tosubstantially reproduce any particular operations, or set of operations,that may be found in the original executable code 10. This may beaccomplished by comparing original instruction codes that are candidatesfor isomorphic substitution with multiple functional isomorphs of whichat least one will be randomly selected for actual substitution into thegenerated polymorphed code 20. In other words, for each discreteoperation of the polymorphic engine 15 as it is applied to the originalcompiled code 10, a different code polymorph 20 version of the originalprogram 10 is generated which has physically different instructions, butsubstantially the same functional characteristics of any other codepolymorph 20. This relationship among multiple code polymorphs 21-24 isdepicted in FIG. 2, wherein no two code polymorphs contain physicallyidentical code, but all of the code polymorphs 21-24 operate to producesubstantially the same functional result. This relationship may berepresented by the following: 2 i=1 n X{circumflex over ( )}O{circumflexover ( )}=X{circumflex over ( )}1*+X{circumflex over ( )}2*+X{circumflexover ( )}3*+X {circumflex over ( )}n*

-   -   wherein, multiple application of the polymorphic algorithm 15        ({circumflex over (X)}) to the original compiled code 10 ( )        generates a series of code polymorphs 21-24 ({circumflex over        (X)}*.sub.i). These code polymorphs 21-24 ({circumflex over        (X)}*.sub.i) have the relationship of {circumflex over        (X)}*.sub.i.noteq.{circumflex over (X)}*.sub.j, which is to say        that no two code polymorphs are statistically physically        identical to each other. However, the code polymorphs 21-24        ({circumflex over (X)}*.sub.i) also have the relationship of        3i=1nX{circumflex over ( )}*=n(o).

As such, they operate to substantially produce the same functionalresult when applied to the set of data, parameters and/or variables(.PSI.) typically operated on by the originally compiled code 10 ( ).

Once the code has been randomly polymorphed, it becomes statisticallyimpossible to retrieve the original application source code.Additionally, each polymorphed copy 21-24 of the application randomlydiffers from any other copy, precluding the possibility of generating apatch or crack for any one polymorphed copy that will work genericallywith any other polymorphed copy of the application. Moreover, in analternative exemplary embodiment, the code polymorphing process may beiteratively applied to generate multiple layers of protection by loopingthe generated code polymorph back through the polymorphic engine asdepicted in FIG. 3, such that a layered code polymorph 25 is produced.

In one exemplary aspect, the method for processing 120 executable code10 to generate a polymorphed code variant 20 may be thought of as“wrapping” or “applying a wrapper to” the original executable. Inanother exemplary embodiment, wrapping 120 of the polymorphed codeadditionally enciphers the polymorph 20 to further subvert attempts toreverse engineer the application. FIG. 20 shows a generic prior artprocess for encrypting/decrypting 620 the code 610 of an at leastpartially encrypted program 600. As the prior art program 600 iscompiled, the decryption algorithm 620 is generally both known andstored in the executable application code; therefore, the encrypted codeblock 610 can be directly added at the compiling stage. However, inaccordance with an exemplary aspect of one embodiment of the presentinvention, as shown in FIG. 21, a random cipher algorithm 650 isgenerated during the wrap process 120 to encrypt the code 640 of theprotected application 630. This random cipher algorithm 650 is generatedin situ and, therefore, generally not known or available to thepolymorphic engine 15 during the wrapping process. Because the cipheralgorithm 650 is not known at the time of wrapping, the newly createdrandom cipher algorithm 650 must be executed in order to correctlydetermine the result to apply to subsequent layers for providingadditional encryption of the code segment 640. The random cipheralgorithm 650, in an exemplary embodiment of the present invention, ismathematically symmetric such that the inverse of the algorithm decryptsthe enciphered block.

Generally, the ability of polymorphed code variants to remain securelyprotected will be at least partially dependent on the ability of thepolymorphic application to resist hacking and/or cracking attacks. Inorder to protect the polymorphic engine 15 itself from debugging,decompilation and/or reverse engineering by, inter alia, analysis ofmemory snap-shots, a running line encryption method may also beemployed. In an exemplary embodiment of the present invention, runningline encryption operates to protect the polymorphic engine 15 while theengine's code resides in memory. This is generally accomplished by (1)encrypting the polymorphic algorithm's compiled instruction code, (2)having only one line of the engine's encrypted instruction codedecrypted for any given CPU instruction cycle, and (3) re-encrypting theinstruction code after the instruction has been executed. As programexecution flow moves the polymorphic engine's code through the stack tobe processed by the CPU, these instructions are decrypted just-in-timeto be provided to the CPU for execution, and then immediatelyre-encrypted before the decryption and subsequent execution of the nextline of instruction code.

In one exemplary embodiment of the present invention, the running lineencryption encoding process proceeds by: (1) calculating the originalopcode length; (2) exclusive or'ing (XOR) the first byte of the opcodeusing a key generated by a random number generation routine (RNG); (3)employing an encryption algorithm to encipher the first byte of theopcode; and (4) sequentially stepping through the original opcode torepeat steps (1)-(3) on subsequent instructions. It will generally beunderstood by those skilled in the art that any encryption algorithm,including, but not limited to, RSL, public/private key encryption, etc.now known or hereafter derived by those skilled in the art, may be usedto encipher the opcode at step (3). The runtime decoding operation ofthe running line encryption process, in one exemplary embodiment,proceeds by: (A) decrypting the first byte of enciphered instruction;(B) providing the decoded instruction to the CPU for processing; (C)re-encrypting the first byte of the instruction after processing; and(D) sequentially stepping through the encrypted instruction code torepeat steps (A)-(C) to execute the enciphered program.

FIG. 12 depicts an exemplary process that utilizes the disclosed runningline encryption feature according to one embodiment of the presentinvention. Line 1 is a line of instruction code that has already beenprovided to the CPU for execution and subsequently re-encrypted. Line 2represents an instruction that is currently decrypted and running. Line3 shows a line of instruction code that will subsequently be decryptedand executed after execution and re-encryption of Line 2 has beencompleted.

In another exemplary embodiment, the present invention also includes avirtual CPU instruction set pre-processor that uses a matchable datastructure, which is randomly created when the polymorphed applicationinitializes. The matchable data structure may comprise, for example, alook-up table, a database, a symmetrical correlation algorithm, anasymmetric correlation algorithm, a functional algorithm, a parametricalgorithm, a one-way function, or any method for correlating a first setof data with at least a second set of data now known or hereafterderived by those skilled in the art. In accordance with one exemplaryembodiment, the matchable data structure correlates instructionsspecific to the CPU's instruction set with virtual CPU opcodes generatedby the polymorphic engine; thus, the original opcodes are replaced withnonsensical random context instructions. The virtual CPU pre-processor,in accordance with another exemplary aspect, may function to furtherobscure polymorphed code by: (1) calculating the original opcode length;(2) using a matchable data structure to convert the original opcode intoa random context instruction; and (3) placing the random contextinstruction code on the same line as the original code so thatcorrelation with the original code is generally accomplished bydetermining the location of the random context code in the instructioncode stream. In a further exemplary aspect, two matchable datastructures may be used, wherein one data structure correlates theoriginal CPU instructions with random numbers and the other datastructure correlates the random numbers of the first data structure withrandom context instruction codes. In yet a further exemplary aspect ofthe present invention, a customized import table may be constructed froman original instruction code table whose contents are overwritten witherroneous information. Other methods, now known or hereafter derived inthe art, may be used to correlate original CPU instructions with randomcontext instruction codes in accordance with the present invention.

In yet another exemplary embodiment of the present invention, anotherlayer of protection is provided by a call mutation feature that operateswith the polymorphic engine to further impede attempts to analyze andreverse engineer application code. Many applications and/or operatingsystems use member calls to classes where the calls generally containheader data for the class member to function properly. Call mutationoperates as a execution sequence redirector by: (1) overwriting theheader of the original call with erroneous data, thereby effectivelydestroying the original call; (2) rerouting the original call to asubstitute call in which the substitute routine queries the stackpointer to determine where the substitute routine has been called from;and (3) comparing the data obtained from the stack to, for example, alook-up table in order to pass program execution control to anappropriate routine. In one exemplary aspect, the overall function ofthe application is substantially the same, but the header of theoriginal call is destroyed and not easily traced. This process can beiteratively applied to generate multiple layers of protection and mayalso be applied to pointers as well.

FIG. 8 depicts an exemplary application of the call mutation routineaccording to one exemplary embodiment of the present invention. Themutator looks at the information contained in the original header of acall (step 200) and then analyzes each line of code in the applicationto determine where the codebase offsets are (step 210) in the programthat call the particular routine of interest. A table of offsets is thengenerated (step 220) for that particular call. When the operating systemloads and initializes the polymorphed application 20, the overwrittenheaders of the original calls will contain erroneous information (step230) and the original calls are replaced with calls to mutationresolution routines (step 240) of the polymorphic engine 15. Themutation resolution routine, according to an exemplary aspect, queriesthe program stack to determine the origin of the resolution routine. Thestack value is then compared to a matchable data structure to determinewhich routine to pass program execution control to and the resolvedroutine is called with accurate header information (step 250) that mayor may not be encrypted.

In a more specific exemplary embodiment, the call mutation routine scanspolymorphed code for API calls such as, for example: CALL [API_NAME];JMP [APINAME]; MOV Register, [API_NAME]; etc. This data is used togenerate an extended instruction pointer (EIP) table in which EIP's, asthe offset from the base address, are correlated to API pointers, asshown in FIGS. 13 and 14.

FIG. 13 depicts an EIP look-up table and FIG. 14 depicts an importaddress table having an indexed, encrypted list of the original APIplace holders. FIG. 15 shows how calls may be mutated in accordance withone exemplary embodiment of the present invention. Thereafter,occurrences of the original calls are replaced with calls to thepolymorphic engine 15, as representatively shown in FIG. 16 for theINTEL.RTM. instruction set.

Decoding and resolution of the mutated calls may be accomplished, in oneexemplary embodiment of the present invention, by (1) the polymorphicengine 15 obtaining the EIP for the particular calling line of code; (2)determining the destination address from the EIP look-up table, based onthe EIP reference from the stack pointer; (3) correlating the AIP placeholder in the import address table; (4) decrypting the AIP data; (5)conditioning the stack frame so that control is passed back to the lineof instruction code immediately following the EIP on the stack; (6)determining if the program redirection is of the CALL or JMP type, andif so, performing a call to the original API; and (7) determining if theprogram redirection is instead of the MOV type, and if so, returning theoriginal value in the appropriate register with minimal or no furtherexecution of a call.

In yet another exemplary embodiment, a secure output display interfacefor concealing data may also be used to protect users from applicationsthat may use operating system calls to capture data by placing a hookinterface between OS routines and a hardware input device (i.e., from akeyboard, mouse, light pen, etc.). This is generally accomplished bycapturing, interpreting and modifying device input before it is madeavailable to other OS processes. FIG. 4 shows a prior art edit textbox30 which bidirectionally communicates with the operating system 35 andmay be directly interrogated to provide the original data from the inputdevice 40 corresponding to the displayed textbox data which isconcealed, in this example, by asterisk characters. FIG. 5, however,depicts a system and method in accordance with one embodiment of thepresent invention, in which the edit textbox 32 is protected frombidirectional communication with the operating system 35. This isgenerally accomplished with a secure hook-capture display interface 38which receives data from an input device 40 and masks that data from theoperating system 35.

The hook-captured input is enciphered and hidden from the OS 35. Forexample, a user password “ABC” to be entered into a textbox 32 can behook-captured from, for example, the keyboard device driver, encipheredand stored, and then the hook routine passes literal asteriskscharacters “***” to the textbox 32. Queries from other OS routines tothe textbox object 32 would return the series of asterisks characters“***” placed there by the hook routine and not the literal text “ABC”entered by the user. In one of the various exemplary aspects of thepresent invention, the hook-capture routine would help to secure userinput to and/or from the polymorphed application 20 by modifying displaydevice output as well as corresponding literal data object content.

FIG. 6 shows a security feature, in accordance with yet anotherexemplary embodiment of the present invention, that utilizes a securehardware input device interface (i.e., keyboard, mouse, light pen,Ethernet cards, etc.) for entering secure data content. In one aspect ofthe present invention, the polymorphed application 20 communicates withan encryption chip 60 located within, for example, a keyboard 55 to tellthe keyboard when encrypted communication is desired. All othercommunication with the keyboard 55, in absence of the request forencrypted data traffic, will be unencrypted. Encrypted data streams fromthe keyboard 55 are preferably decrypted at the polymorphed codeapplication level 20, not the device driver 50, hardware abstractionlayer 45 or OS 35 levels, in order to prevent background applicationsfrom obtaining the decrypted data stream. In a preferred exemplaryembodiment, the input device encryption chip 60 would only ever besignaled to use encrypted data traffic when the polymorphed application20 is brought into use focus.

FIG. 7 shows yet another embodiment of the present invention in which asecure software application for entering, for example, authenticationinformation (i.e., username and password data, etc.) is depicted. Theapplication is a dynamic, randomly configured, graphical keypad display,which is designed to subvert optical capture/recognition and hardwareinput device logging. In one exemplary embodiment of the presentinvention, the graphical keypad comprises standard numbered keys, adelete key and an enter key which are randomly arranged in the keypadmatrix. In addition to the keypad, there are four cursor keys 70. As thegraphical keypad is initialized, a random keypad position is selectedand highlighted. The four cursor keys permit the user to reposition thehighlight over the key to be entered. When the highlighting cursor ispositioned over a key, the display flashes the value corresponding tothe highlighted key and then quickly obscures the key value. When theenter key has been depressed, the keypad display is cleared and thehighlighting cursor is again randomly repositioned on the keypad. Thedynamic display features subvert display screen-shot attempts todetermine the key that has been depressed, while the randomreconfiguration of the keypad for each keypad entry also subvertskeyboard logging attempts. Such a graphical keypad application may beused, for example, to improve the security of data entered into anexecuting polymorphed application in accordance with an exemplaryembodiment of the present invention.

FIG. 9 depicts a layered security diagram for securely executingapplication code in accordance with yet another exemplary embodiment ofthe present invention. In the top most layer, a checksum is calculatedwith modification of any deeper layer resulting in an invalid checksumbeing calculated (step 315). In the next layer, the polymorphicdecryption engine is started using running line encryption withmodification of any deeper or higher layer causing the decryption tofail (step 314). In the next layer, validation of the checksum iscalculated from step 315 with any modification causing a checksum error(step 313). The next lower layer erases the previous block, destroyinghigher layers in memory and making rebuilding very tedious (step 312).Thereafter, an internal import table is populated with values while theimport table references in the executable code are obscured; tamperingwith this layer will cause the executable to not work (step 311). In thenext layer, running line is started with a CRC, erasure of the previousblock, and decoding of the next block with a CRC key; a single bytechange in a deeper or higher layer causes the destruction of the nextblock of data (step 310). The next layer decrypts sections of therunning line with the running line being based on the executable code'sCRC; modification of any deeper or higher layer will cause invalid dataproduction (step 309). In the next layer, a CRC of, for example, aportable executable (PE) header is performed with storage of the CRC forchecking at a lower security level (step 308). The PE header is the datablock which enables the WINDOWS.RTM. OS to correctly load and execute aWIN32 executable. The next layer installs timer code designed to triggera CRC check (step 307). In the next layer, an import table is createdusing the layer at step 311 to determine the actual import table to beused (step 306). The next lower layer of security decrypts resourcesections with the decryption based on all layers both above and below;any change will result in invalid data being produced (step 305). In thenext layer, the previous instruction is erased and the next instructionis decrypted with deletion of parts of the executable code occurring aseach block is decrypted, making a full rebuild very difficult (step304). In the next layer, the code entry point is decoded and programexecution jumps to the entry point with decryption of the original entrypoint of the program based on all above layers. Also at this level,execution of the original program is initialized (step 303). In the nextlayer of security, a check is made for breakpoints on each API call madewith deletion of hardware breakpoints to defeat debugging attempts (step302). In the bottom layer, a verification of non-modification isperformed every ‘n’ seconds to check for debugging attempts by comparingmemory CRC's with disk CRC's from the layer at step 315 (step 301).

In a further representative aspect of the present invention, layeredsecurity methods, such as, for example, the described exemplaryembodiment in accordance with steps 315-301, may be used to detect, forexample, the presence and/or operation of a computer virus. Moreover, itwill be apparent to those skilled in the art that while each securitylayer (steps 315-301) may individually provide suitable protection forthe execution of a computer application, the combination of securitylayers, and the interoperability of the component features of the same,offers substantial benefits with respect to the discrete implementationof any single component security feature by itself.

FIG. 17 depicts yet another exemplary embodiment of the presentinvention. Often, copies of software applications may be distributed forprovisional use in anticipation of provisional end-user testing of thesoftware to determine whether a license will be purchased. Generally,software may be distributed in a restricted or crippled format, forexample, by not permitting a provisional user to save or print adocument created with the provisional version of the application. Otherrestrictive methods may render the provisional software applicationentirely unusable after the expiration of a given period of time.

An exemplary application of the security features of the presentinvention described herein, is directed to a “try-before-you-buy”implementation. Generally, this may be accomplished, in onerepresentative aspect, by allowing the software developer to insert amacro or marker into the original source code 400 (Step “xSecure_Start .. . xSecure_End”) which instructs the polymorphic engine 15 wrapper toencrypt the designated code block (Step “DO Cool Stuff( ) . . . ”) toavoid execution without a valid key. The source code 400 is thencompiled to produce executable code 410. During polymorphic wrapping420, an encryption method is selected which is suitably adapted suchthat brute force decryption attempts would generally not be practicablewith industry standard equipment. When the protected application isformally licensed and/or registered (“read purchased”), a key issupplied to the user which is mathematically customized to the signatureof the application's operating environment. A “fingerprint” key may beconstructed as a function of, for example, software/hardware systemcomponent information, network connectivity data, user identificationdata, CPU serial numbers, etc. or any other information now known orhereafter derived by those skilled in the art. The key is combined witha calculated fingerprint signature, and the protected code blockdecrypted using the resulting combination 430. If the application isported to a different machine, or executed without a valid key, thedecryption will fail and, for example, a warning may be displayedindicating that the software is operating in a demonstration ortrial-use mode.

In another exemplary aspect of an embodiment of the present invention,the program stack may be manipulated to further subvert attempts toreverse engineer application code. FIG. 18 generally depicts genericprior art relationships existing between application code 500,application data 510 and the program stack 520. FIG. 19, however, showsan exemplary embodiment of the present invention having differentrelationships among these same components: application code 530,application data 540 and the program stack 550. A first context(“Context A”, see 505 and 535) is generally comprised of the applicationcode and the application data in both the prior art embodiment and thepresent exemplary inventive embodiment. Additionally, a second context(“Context B”, see 515 and 545) is generally comprised of the programstack in the prior art embodiment and the exemplary inventive embodimentas well. One difference between the prior art and the present exemplaryinventive embodiment, however, involves what happens when a memory dumpor memory snap-shot occurs in an attempt to address and/or reverseengineer the code.

In the prior art embodiment, interrogation of memory will generallyproduce only the information corresponding to Context A 505, but theinformation of Context B 515 is contained in the data of Context A 505by virtue of the “PUSH POINTER MSG” instruction (See 500). Therefore,the prior art code is susceptible to reverse engineering. In accordancewith one aspect of the present exemplary embodiment, when a memoryinterrogation of Context A 535 occurs, substantially all informationcontained in Context B 545 is lost in such a fashion that theinformation generally cannot be regenerated from the contents of ContextA 535. This occurs because the polymorph wrap process dynamicallyreplaces the original code with a new call which is written directly tothe stack. In other words, the call to the unwrapping code of thepolymorphic wrapper application 15 is placed on the stack and generallynever in the code of the protected application itself. The code on thestack 550, therefore, is generated in situ and concurrent with theremoval of the original code. In another exemplary embodiment of thepresent invention, the original code may or may not be encrypted. In yetanother exemplary embodiment of the present invention, the system andmethod depicted in FIG. 19 may also be used for API call redirection aswell.

In still other exemplary embodiments, the system of the presentinvention may include a host server or other computing systems includinga processor for processing digital data, a memory coupled to saidprocessor for storing digital data, an input digitizer coupled to theprocessor for inputting digital data, an application program stored insaid memory and accessible by said processor for directing processing ofdigital data by said processor, a display coupled to the processor andmemory for displaying information derived from digital data processed bysaid processor and a plurality of databases, said databases includingdata that could be used in association with the present invention. Thedatabase may be any type of database, such as relational, hierarchical,object-oriented, and/or the like. Common database products that may beused to implement the database include DB2 by IBM (White Plains, N.Y.),any of the database products available from ORACLE.RTM. CORPORATION(Redwood Shores, Calif.), MICROSOFT.RTM. ACCESS by MICROSOFT.RTM.CORPORATION (Redmond, Wash.), or any other database product. Thedatabase may be organized in any suitable manner, including, forexample, data tables, look-up tables or any matchable data structuresnow known or hereafter derived in the art.

Association of certain data may be accomplished through any dataassociation technique known and practiced in the art. For example, theassociation may be accomplished either manually or automatically.Automatic association techniques may include, for example, a databasesearch, a database merge, GREP, AGREP, SQL, and/or the like. Theassociation step may be accomplished by a database merge function, forexample, using a “key field”. A “key field” partitions the databaseaccording to the high-level class of objects defined by the key field.For example, a certain class may be designated as a key field in boththe first data table and the second data table, and the two data tablesmay then be merged on the basis of the class data in the key field. Inthis embodiment, the data corresponding to the key field in each of themerged data tables is preferably the same. However, data tables havingsimilar, though not identical, data in the key fields may also be mergedby using AGREP, for example.

The present invention may be described herein in terms of functionalblock components, screen shots, optional selections and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the presentinvention may employ various integrated circuit components, e.g., memoryelements, processing elements, logic elements, matchable datastructures, and the like, which may carry out a variety of functionsunder the control of one or more microprocessors or other controldevices. Similarly, the software elements of the present invention maybe implemented with any programming or scripting language such as, forexample, C, C++, Java, COBOL, assembler, PERL, extensible MarkupLanguage (XML), etc., or any programming or scripting language now knownor hereafter derived in the art, with the various algorithms beingimplemented with any combination of data structures, objects, processes,routines or other programming elements. Further, it should be noted thatthe present invention may employ any number of conventional techniquesfor data transmission, signalling, data processing, network control, andthe like. Still further, the invention could be used to detect orprevent security issues with a client-side scripting language, such asJavaScript, VBScript or the like. For a basic introduction ofcryptography, please review a text written by Bruce Schneider entitled“Applied Cryptography: Protocols, Algorithms, And Source Code In C,”published by John Wiley & Sons (second edition, 1996), which is herebyincorporated by reference.

It should be appreciated that the particular implementations shown anddescribed herein are illustrative of the invention and its best mode andare not intended to otherwise limit the scope of the present inventionin any way. Indeed, for the sake of brevity, conventional datanetworking, application development and other functional aspects of thesystems (and components of the individual operating components of thesystems) may not be described in detail herein. Furthermore, theconnecting lines shown in the various figures contained herein areintended to represent exemplary functional relationships and/or physicalcouplings between the various elements. It should be noted that manyalternative or additional functional relationships or physicalconnections may be present in a practical system.

It will be appreciated, that many applications of the present inventioncould be formulated. One skilled in the art will appreciate that thenetwork may include any system for exchanging data, such as, forexample, the Internet, an intranet, an extranet, WAN, LAN, satellitecommunications, and/or the like. It is noted that the network may beimplemented as other types of networks, such as an interactivetelevision (ITV) network. The users may interact with the system via anyinput device such as a keyboard, mouse, kiosk, personal digitalassistant, handheld computer (e.g., Palm Pilot.RTM.), cellular phoneand/or the like. Similarly, the invention could be used in conjunctionwith any type of personal computer, network computer, workstation,minicomputer, mainframe, or the like running any operating system suchas any version of Windows, Windows XP, Windows Whistler, Windows ME,Windows NT, Windows2000, Windows 98, Windows 95, MacOS, OS/2, BeOS,Linux, UNIX, or any operating system now known or hereafter derived bythose skilled in the art. Moreover, the invention may be readilyimplemented with TCP/IP communications protocols, IPX, Appletalk, IP-6,NetBIOS, OSI or any number of existing or future protocols. Moreover,the system contemplates the use, sale and/or distribution of any goods,services or information having similar functionality described herein.

The computing units may be connected with each other via a datacommunication network. The network may be a public network and assumedto be insecure and open to eavesdroppers. In one exemplaryimplementation, the network may be embodied as the internet. In thiscontext, the computers may or may not be connected to the internet atall times. Specific information related to data traffic protocols,standards, and application software utilized in connection with theInternet may be obtained, for example, from DILIP NAIK, INTERNETSTANDARDS AND PROTOCOLS (1998); JAVA 2 COMPLETE, various authors, (Sybex1999); DEBORAH RAY AND ERIC RAY, MASTERING HTML 4.0 (1997). LOSHIN,TCP/IP CLEARLY EXPLAINED (1997). All of these texts are herebyincorporated by reference. A variety of conventional communicationsmedia and protocols may be used for data links, such as, for example, aconnection to an Internet Service Provider (ISP) over the local loop asis typically used in connection with standard modem communication, cablemodem, Dish networks, ISDN, Digital Subscriber Line (DSL), or variouswireless communication methods. Polymorph code systems might also residewithin a local area network (LAN) which interfaces to a network via aleased line (T1, D3, etc.). Such communication methods are well known inthe art, and are covered in a variety of standard texts. See, e.g.,GILBERT HELD, UNDERSTANDING DATA COMMUNICATIONS (1996), herebyincorporated by reference.

As will be appreciated by one of ordinary skill in the art, the presentinvention may be embodied as a method, a system, a device, and/or acomputer program product. Accordingly, the present invention may takethe form of an entirely software embodiment, an entirely hardwareembodiment, or an embodiment combining aspects of both software andhardware. Furthermore, the present invention may take the form of acomputer program product on a computer-readable storage medium havingcomputer-readable program code means embodied in the storage medium. Anysuitable computer-readable storage medium may be utilized, includinghard disks, CD-ROM, optical storage devices, magnetic storage devices,and/or the like.

Data communication is accomplished through any suitable communicationmeans, such as, for example, a telephone network, Intranet, Internet,point of interaction device (point of sale device, personal digitalassistant, cellular phone, kiosk, etc.), online communications, off-linecommunications, wireless communications, and/or the like. One skilled inthe art will also appreciate that, for security reasons, any databases,systems, or components of the present invention may consist of anycombination of databases or components at a single location or atmultiple locations, wherein each database or system includes any ofvarious suitable security features, such as firewalls, access codes,encryption, de-encryption, compression, decompression, and/or the like.

The present invention is described herein with reference to screenshots, block diagrams and flowchart illustrations of methods, apparatus(e.g., systems), and computer program products according to variousaspects of the invention. It will be understood that each functionalblock of the block diagrams and the flowchart illustrations, andcombinations of functional blocks in the block diagrams and flowchartillustrations, respectively, can be implemented by computer programinstructions. These computer program instructions may be loaded onto ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions which execute on the computer or other programmabledata processing apparatus create means for implementing the functionsspecified in the flowchart block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, it will be appreciated thatvarious modifications and changes can be made without departing from thescope of the present invention as set forth in the claims below. Thespecification and figures are to be regarded in an illustrative manner,rather than a restrictive one, and all such modifications are intendedto be included within the scope of present invention. Accordingly, thescope of the invention should be determined by the appended claims andtheir legal equivalents, rather than by merely the examples given above.For example, the steps recited in any of the method or process claimsmay be executed in any order and are not limited to the order presentedin the claims.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as critical, required, or essentialfeatures or elements of any or all the claims. As used herein, the terms“comprises”, “comprising”, or any other variation thereof, are intendedto cover a non-exclusive inclusion, such that a process, method,article, or apparatus that comprises a list of elements does not includeonly those elements but may include other elements not expressly listedor inherent to such process, method, article, or apparatus. Further, noelement described herein is required for the practice of the inventionunless expressly described as “essential” or “critical”. Othercombinations and/or modifications of the above-described structures,arrangements, applications, proportions, elements, materials orcomponents used in the practice of the present invention, in addition tothose not specifically recited, may be varied or otherwise particularlyadapted by those skilled in the art to specific environments,manufacturing or design parameters or other operating requirementswithout departing from the general principles of the same.

1. System for securely executing a first compiled application to modifyinstruction code of a second compiled application while substantiallypreserving operational and functional characteristics of the secondcompiled application comprising: means for enciphering the firstcompiled application; means for decrypting a first line of instructioncode of the first compiled application and generating decryptedinstruction code; means for executing the decrypted instruction code;means for re-enciphering the decrypted instruction code prior todecrypting and executing a next line of instruction code of the firstcompiled application; and means for sequentially decrypting instructioncode, executing decrypted instruction code, and re-enciphering decryptedinstruction code to execute the first compiled application.
 2. Method ofsecurely executing a compiled application comprising: enciphering thecompiled application; decrypting a first line of instruction code of thecompiled application and generating decrypted instruction code;executing the decrypted instruction code; re-enciphering the decryptedinstruction code prior to decrypting and executing a next line ofinstruction code of the compiled application; and sequencing saiddecrypting, said executing and said re-enciphering to execute thecompiled application.
 3. Method of claim 2, wherein said encipheringcomprises: XOR'ing a first byte of instruction code of the compiledapplication with a key and generating an XOR'ed byte; encrypting theXOR'ed byte; and sequencing said XOR'ing and said encrypting to encipherthe compiled application.
 4. Method of claim 3, wherein said key isgenerated with a random number generation function.
 5. Method of claim2, wherein said re-enciphering comprises: XOR'ing a first byte of thedecrypted instruction code with a key and generating an XOR'ed byte; andencrypting the XOR'ed byte.
 6. Method of claim 5, wherein said the keyis generated with a random number generation function.